1. Field of the Invention
The present invention relates to the field of automated system configuration, and more particularly to the configuration of systems that include groups of components spanning more than one context, such as a product line.
2. Description of the Related Art
The growth of commerce conducted over the Internet has engendered numerous techniques by which automated business transactions may be facilitated between buyers and sellers. One such technique is automated product configuration. Automated configuration is typically offered to potential buyers by sellers of complex systems which are typically products made up of large numbers of interconnected components, such as computers, servers, automobiles, or any product which may present multiple combinations of component options to a potential buyer. Typically, the seller provides a user interface (UI) by which the buyer is guided through a process of selecting among various options and quantities thereof in configuring a product or system for purchase, and often provides the buyer with a price quote for the desired combination of options as specified by the buyer through the UI.
When configuration is offered over the Internet, the buyer typically accesses a product configurator using a browser over the Internet. The buyer's selections are typically captured by the control inputs of the UI that is executed and displayed using the buyer's web browser. The selections are transmitted over the Internet by the browser in the form of requests to a server running an application on behalf of a seller. The transmission of requests is typically initiated over the Internet in response to an action taken by the buyer that indicates that the buyer has made the desired selections and would like to initiate the configuration process. The server running the configuration application program receives the requests (i.e. processes the values or states of the control inputs of the UI) and initiates the configuration process, which generates a virtual configuration of the product based on the user selections embodied by the requests. Often, the application then derives a price quotation based on the configuration, which can be transmitted back to the user for display by the browser.
The application server typically interfaces with a database that, at a minimum, is a repository for information characterizing or modeling all of the possible components that may be requested or required to be configured as part of the system. The model maintains the components and their attributes, as well as any constraints that must be met during the installation of those components within a system. Often the model is defined using an object-oriented language that represents components as classes specifying attributes and constraints of each class of component. The attributes and constraints are given values upon each instantiation of a member of the class, and the constraints must be met during installation of each instantiation within the system configuration. The model may represent the classes of components hierarchically using a number of criteria.
One very important hierarchical criterion is product line. A product line hierarchy defines classes of components all of which are compatible with one another (i.e. the manufacturer typically has qualified the components of a given product line as compatible per extensive testing). Some components may be shared across product lines. For example a system rack or chassis may be shared across many server product lines, even though the components residing in the chassis may be quite different for different product lines. Organizing classes of components in accordance with their product lines permits significant simplification of the model because the model does not have to comprehend all of the attributes that make the components of a product line compatible with one another. Rather, the model can be built under the simple assumption that classes of components belonging to a given product line work together, subject to more specific constraints regarding their installation with one another. Such constraints may include components that are required to be installed along with the requested component, or demands for connections between components.
Constrained by the requests from the buyer, as well as those constraints associated with each component as specified by the model, the components are typically instantiated and then installed by a configuration engine. Some configuration engines are incremental in nature, and they install one component at a time. If the component can not be successfully installed as part of the current configuration, the configurator backs up and tries to find another component candidate that meets the requests of the user and that is compatible with the current state of the configuration. If no such component can be found, the configurator backs up to a previously installed component, and attempts to select another from a list of candidates for that component. The configurator iteratively performs this process until a workable combination of components has been assembled, or it becomes clear there is no workable combination. One example of an incremental configurator is disclosed in U.S. Pat. No. 5,515,524 entitled, “Method and Apparatus for Configuring Systems,” which is incorporated herein in its entirety by this reference.
Configurators such as the one described above use statements such as requires_component or the like to create decision points for the configurator to choose between viable candidates for components to be installed, for example, as required by the installation of another component. Typically, the installation process as well as the decision as to what additional component to instantiate and then install in response to a requires_component is performed by a configuration engine in view of the constraints for those components in the model. The engine is typically optimized to search for possible candidates to satisfy a requires_component, based on the product line attribute. A candidate queue is generated containing all of the possible choices that meet the class of components defined by the requires_component statement and that fall into the appropriate product line. The engine proceeds to instantiate and then to attempt installation starting with the first candidate in the queue, and so on until installation is successful. The instantiation of an object component and the installation of that object in response to a requires_component statement may also lead to additional requires_component decision points as dictated by the constraints of each component being instantiated and installed.
Thus, the configurator benefits from the use of the product line hierarchy to limit the number of components in a candidate queue to only those components compatible with the other components already installed in the configuration. Sellers often have vast numbers of components spanning numerous product lines that are included in a model used to configure their systems. Thus, were the list of candidates to include all components of all product lines, the candidates list would become enormous and unwieldy. This technique for keeping candidates queues small and manageable works quite well for homogenous systems or products (i.e. those systems configured from components belonging to a single product line). When a buyer desires to configure a system that combines product components from different product lines (i.e. heterogeneous systems or products), however, keeping candidate queues small becomes problematic. This is because the engine must be able to “see” all possible candidates that can be included in the overall configuration, which spans the multiple product lines to be included in the system configuration.
The inclusion of components in decision candidate queues from two or more product lines can result in an exponential growth of potential candidates from which the configurator may choose components to satisfy component requirements of other components being installed in the configuration of the system or product. The configuration of components from multiple product lines might occur if, for example, a buyer wishes to mix two servers each from a different product line in one larger system in which the servers share a common rack and perhaps a shared external memory or a PDU. The components of the shared memory or PDU typically belong to the product lines of both servers. The two servers may also share a system rack that belongs to both product lines.
Often, the process of configuring a shared resource such as a PDU results in the bringing in of a component by a subsystem in one product line (such as the first server) into a second subsystem in a second product line (such as the second server). The instantiation of the component typically is not a problem because the component probably falls into both product lines. But constraints on the installation of this component common to both product lines may generate subsequent requires_component decision points that must be satisfied by the components that fall exclusively within the product line of the second subsystem. Thus, unless all components from all product lines are available, satisfaction of these subsequent requires_component statements may include incompatible components. Of course as previously discussed, failing to restrain the choice of components to one product line context makes configuration of these heterogeneous systems arduous.
Prior techniques employed to configure heterogeneous systems or products have been difficult to implement and are not very flexible. One technique that has been employed in the past is to configure the heterogeneous system or product in a default product line that includes all product lines of the components represented in the model. But, to keep the candidate queues down to a manageable size, filtering logic had to be written around the decision points to be sure that changes in product line context were made manually at the appropriate points In this way, the model could track when the installation of a component in one product line generates a requires_component or “demand” to install or re-install a component that would also require a change in the product line context to operate correctly, as well as when to change the context back to the previous state or a different state. In this way, only those candidates are included as choices that are actually compatible with a component object the installation of which generated the requires_component or other decision point statement. This technique is extremely complex and burdensome to the modeling process, however, because the logic must be manually constructed for each decision point to keep track of the situations during the configuration process when product line contexts are switched as the configurator moves from one subsystem to another.
Those of skill in the art will recognize that the product line is not the only context which a configurator may wish to dynamically switch between states. Others may include, for example, current component availability in inventory, the country in which the configured system is to work (which may affect choice of components), and many other contexts relevant to the automated configuration of systems.
Therefore, it would be desirable to provide a generic technique whereby a configurator can freely and dynamically switch between product line frames of reference (or other contexts) while configuring heterogeneous, thereby satisfying the decision points during configuration without flooding the configurator with too many choices and without requiring the model to be manually programmed to take account of the circumstances that might lead to a context switch. Moreover, it would also be desirable if the technique was easy to implement and independent of the model.